IBIS Macromodel Task Group

Meeting date: 17 February 2015

Members (asterisk for those attending):
Altera:                       David Banas
ANSYS:                      * Dan Dvorscak
                              Curtis Clark
Avago (LSI)                   Xingdong Dai
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
eASIC                         Marc Kowalski
SiSoft:                       Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad: We need to discuss ground issues in the IBIS specification.


--------------------------
Call for patent disclosure:

- None


-------------
Review of ARs:

- Michael M send BIRD proposal to Mike L for posting.
  - Sent today.

- Mike L post link to Randy's presentation.
  - Done (just now).

- Arpad to review IBIS specification for min max issues.
  - In progress.


-------------
New Discussion:

C_comp enhancements:

- Michael M showed IBIS-AMI and Direction Indication.
- Michael M: There is an enable function in 3-state and I/O buffers.
  - If I have a bidirectional analog model the algorithmic model.
    should have all that is needed for both directions.
- Ambrish: If an I/O is present it can have only RX capability?
- Michael M: It has to present the right data for the state it is in.
  - Two Reserved_Parameters are proposed:
    - AMI_Model_Type
    - AM_Model_Direction

- Bob: 3-state has two modes, driving and high-Z.
- Michael M: the high-Z mode is covered by AMI_Model_Direction Ignore.
  - There are 3 ways to support this:
    - A single DLL handles all modes.
    - Multiple [Algorithmic Model] sections within a [Model].
    - [Algorithmic Model Selector] within a [Model].
- Arpad: Would #1 require a selector of some sort?
- Michael M: All parameters would be passed, the DLL would adjudicate.
  - This could be tricky to program.
  - It might not be a viable or complete proposal.

- Radek: It would need to have two controls, enable and direction.
- Arpad: We could solve that with something like the way Corner works.

- Michael M: It is assumed AMI_Model_Type is checked against the Model_type.
  - Model_Direction should be set consistently.
- John: We already have the disadvantage of checking that.
  - The specification doesn't have a table for that.

- Michael M: Options 2 and 3 change one sentence in the specification.
  - For option 2 we would have to allow [Algorithmic Model] more than once.
  - We would need a subparam too.
  - Existing models would not have to change.
- Bob: Would this be appropriate for I/O models?
- Michael M: There is a risk of using a TX DLL with an RX analog model.

- Ambrish: Direction would be in the [Algorithmic Model] for cross checking?
- Michael M: That would be needed for option 1.
  - There is a question of how many [Algorithmic Model] sections to allow.
- Arpad: We should disallow having 2 of the same direction.
- Radek: Agree.
  - [Model Selector] might map to [Models] of different directions though.
- Ambrish: What is the advantage of multiple TX models?
- Michael M: Without a selector it's clear.

- John: For 3-state you only have TX, nothing else.
- Arpad: Some would like Terminators for off state.
- Michael M: That is restricted now.
- Radek: Why did we disallow that?
- Arpad: It makes no measurements.
- John: Maybe we need a separate analog model for high-Z state.

- Michael M: [Algorithmic Model Selector] would be between [Model] and [Algorithmic Model]
  - We now can have families of models.
  - This would require names for [Algorithmic Model]s.
  - The tool could find TX models and offer them to the user.
- Arpad:
  - Alternatively the Executable lines could be grouped.
- Michael M:
  - That might be less readable.
- Mike L: The [Algorithmic Model]s could be named after directions
  instead of arbitrary names.
- Michael M: That collapses into option 2.

- Arpad: There could be separate groups of Executable lines.
- Radek: The Executable lines could have an extra field.
- Michael M: That would work as long as we would not need more fields.
- Arpad: I had a group name keyword in mind.
- Ambrish: We could remove one of the [Algorithmic Model Selector] columns shown.
- Mike L: Do we need to allow multiple models of the same type?
- Michael M: It might be used for extra corners, for example.
- Ambrish: The user will have to decide which to use.
- Michael M: There could be a conventiona that the "first in the list" is default.

- Ambrish: Would option 2 allow for option 3 later?
- Michael M: It might paint us into a corner.
- John: 3 could be used with 2 if you want multiple models of the same type.
- Michael M: There could be one analog model with different algorithmic models.
   - This could be done with [Model Selector] by repetition.
- John: Protocols can be specified in the AMI file.

- Radek: We should separate directionality from model selection.
- Arpad: Should we move [Algorithmic Model] to component level?
- Michael M: Directionality can be separate, it doesn't depend on hierarchy.
- Arpad: Would option 2 preclude an I/O model?
- Michael M: No, bu the tool will have to let the user choose direction.
- Ambrish: Should we use Output and Input instead of TX and RX?

- Michael M: I will add options 2a and 2b.
  - The table Radek asked for exists.
- Mike: L: I'm seeing TX and RX models shipped separately.
  - There might not be much demand for putting many models in one IBIS file.
- Michael M: This relates to BIRD 161, about IBIS files for buffers, not parts.

AR: Michael M update IBIS-AMI Direction proposal

-------------
Next meeting: 24 Feb 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
